An increasing number of software applications are written to platform independent execution environments such as the Java Runtime Environment and the .NET Common Language Runtime. These applications generally execute within a virtual machine (VM) that provides a level of abstraction between the program execution environment and the external software interface. Applications often use middleware frameworks on top of these execution environments. Examples of such frameworks are J2EE application servers and .NET application servers.
A general purpose device, such as a computer, commonly has finite resources. If each VM's execution resources is provided by the general purpose device, any such device can only support a limited number of applications and VM's. Data centers often need to support a significant number of applications. As a result, a large number of general purpose devices are deployed for resource planning purposes, with each application allotted enough resources for its peak needs, making such a setup costly to deploy and administer.
FIG. 1 is a block diagram illustrating an example system configuration for running web applications using J2EE application server frameworks. A user request is intercepted by a web server 100 and is directed to an appropriate general purpose device 102. Software components including VM 114, application server 116, and application 118 are stored on a data storage device 112 that is accessible from general purpose device 102. At initialization time, the stored software components are loaded into general purpose device 102. The runtime instantiations of the software components include VM 104, application server 106 and application 108. VM 104 launches application server 106, which in turn launches application 108. The application handles the user requests, processes the business logic associated with the requests, and communicates with database 110 if appropriate, and passes the result back to the web server.
Traditionally in order to support a large number of applications, a large number of general purpose devices are deployed to accommodate the peak resource needs of the applications. It is desirable to have a way to provide large scale application support at reduced deployment and administration costs. Also, given the existing investment in middleware frameworks and applications, an effective solution to the problem should be backward compatible with the existing applications and frameworks.
In one solution, the VM segments its functionality into a shell VM and a core VM that are separate. The shell VM performs interactions with the external environment. The core VM performs VM internal execution functions including managing memory, performing computations, transferring data, processing data and processing logic. The core VM communicates through the shell VM for interaction with the external environment. Resources consumed by the core VM are separate, both logically and physically, from those consumed by the shell VM. The external environment does not need to be aware of the VM segmentation and can interact solely with the shell VM. To the external environment, the distribution of VM internal execution functions and shell functions appears transparent. The shell VM appears as a complete VM, even though it does not consume resources needed for VM internal execution.
Since all external network and I/O communications are performed via the shell VM, scaling the performance of the segmented VM can become limited by capabilities of the shell VM host to perform the external communications. Therefore, there exists a need to perform external communications on the segmented VM more efficiently.